Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.89%. Comparing base (8091094) to head (0d5048d).
⚠️ Report is 7 commits behind head on main.
✅ All tests successful. No failed tests found.

@@            Coverage Diff             @@
##             main    #5467      +/-   ##
==========================================
+ Coverage   88.88%   88.89%   +0.01%     
==========================================
  Files         333      333              
  Lines       92082    92082              
  Branches    92082    92082              
==========================================
+ Hits        81850    81860      +10     
+ Misses       6403     6394       -9     
+ Partials     3829     3828       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

CodSpeed Performance Report

Merging #5467 will not alter performance

_{Comparing mgoldenberg:prepare-to-update-indexed-db-futures (0d5048d) with main (92192c5)}

Summary

✅ 6 untouched benchmarks

@andybalaam: thanks for your response! And yes, I believe you have understood correctly!

Now my turn to make sure I am understanding you: the problem is that the web-based Element client uses the crypto_store module of matrix-sdk-indexeddb - presumably as a WASM module? And that the user interface is essentially unresponsive during migrations. Finally, the migration I have added will likely take a long time for many users - depending on how much data they have in inbound_group_sessions3 - and, furthermore, provide no added benefit as the schema hasn't really changed.

That's a rather tricky problem... I hadn't thought about how long the migration might take.

So, the concern with waiting for an upstream patch to indexed_db_futures seems like it will be rather open-ended. Unfortunately, the project appears to be maintained by a single person and their current status on GitHub is: "I'm probs not having a look at that issue you opened anytime soon. Hands full.". This, of course, isn't your problem to fix. It just isn't instilling a lot of confidence that we will see a change any time soon 😅

I will confer with the people at @filament-dm, as this work is being done in service of their client. Perhaps we will have to keep this in their fork until we see some movement elsewhere.

Out of curiosity, do you have any concrete sense of when element-hq/element-web#26892 might be resolved? And is this something I can help with?

Also, tagging @zzorba here, in case he wants to weigh in or has other ideas about how to move forward.

@mgoldenberg yes, I think we are understanding each other very well.

I'd really like to avoid a slow migration for every user when it is not needed. If rust-indexed-db is not being updated, it might make sense to fork it, but I guess the first step would be to open a PR against the project and see whether it gets attention.

Help with fixing element-hq/element-web#26892 would be great - it might need some input from Element Design team to decide how it should look, but we could probably get that, or merge a good-enough solution in the meantime.

BUT the more I think about this the less I like adding a delay for all users simply because of a dependency issue.

I guess part of the question is how urgent this is. Maybe we are prepared to wait a while to see whether rust-indexed-db accepts a contribution. If the only downsides are that we can't test on Chrome and Filament needs to keep this in their fork for a while, maybe we can accept those for a while?